home *** CD-ROM | disk | FTP | other *** search
/ Deutsche Edition 1 / Deutsche Edition 1.iso / amok / amok_lha / amok08.lha / MemSystem1.1e / MemSystem.dok < prev    next >
Text File  |  1993-08-15  |  6KB  |  144 lines
  1. Dokumentation zu "MemSystem" V1.1
  2. Autor: Nicolas Benezan, Postwiesenstr. 2, D7000 Stuttgart 60
  3.  
  4. Übersicht
  5. ---------
  6. MemSystem ist ein Speicherverwaltungsmodul, das gegenüber dem Standardmodul
  7. "Heap" folgende Vorteile aufweist:
  8.  
  9. * es ist voll Multitaskingfähig, d.h. es kann vom Hauptmodul importiert und
  10. von mehreren Tasks aus parallel benutzt werden. Dabei wird allozierter
  11. Speicher immer in der MemList des aufrufenden Tasks eingetragen. Bei
  12. Beendigung des Tasks (mit RemTask oder bei Process-Termination) wird der
  13. gesammte mit MemSystem verwaltete Speicher freigegeben.
  14. * Wird mehr Speicher angefordert als frei ist, wird dies nicht sofort mit
  15. NIL beantwortet, sondern ein Requester (Retry/Cancel) erzeugt. Der Benutzer
  16. hat somit die Möglichkeit, z.B. einige Workbench-Windows zu schließen, um
  17. es dann noch einmal zu probieren. Der Programmieraufwand ist praktisch
  18. null, entgegen der sonst üblichen Methode, dach jedem AllocMem() auf NIL zu
  19. testen, den Requester anzuzeigen ...
  20. * System-Deadlocks, die durch extremen Speichermangel hervorgerufen werden
  21. können, werden verhindert. Viele Programme erzeugen bei Speichermangel eine
  22. Meldung mit AutoRequest() (zB. auch der Modula-Compiler). Es wird aber oft
  23. vergessen, daß der Requester selbst auch Speicher benötigt. MemSystem
  24. berücksichtigt dies.
  25.  
  26. Außerdem wurden noch einige nützliche Prozeduren implementiert:
  27.  
  28. * Eine vereinfachte AutoRequest()-Prozedur
  29.  
  30. * Prozeduren zum Abbruch des Programms entweder über Retry-Cancel-
  31. Requester oder ähnlich der Arts.Error-Prozedur oder ohne irgendeine Meldung
  32.  
  33.  
  34. Allocate, AllocMem, Deallocate
  35. ------------------------------
  36. Diese Prozeduren entsprechen in der Schnittstelle sowie in der Handhabung
  37. genau den gleichnamigen Prozeduren von Heap. Allerdings läuft beim
  38. allozieren von Speicher für das aufrufende Programm unsichtbar noch
  39. folgendes ab:
  40. * Es wird getestet, ob Size+MinMemory Speicher frei ist.
  41. * falls nicht wird ein Requester (Low Memory Warning Retry/Cancel) erzeugt.
  42. Bei "Retry" wird noch einmal versucht, die angeforderte Speichermenge zur
  43. verfügung zu stellen. Bei "Cancel" wird NIL zurückgegeben, wie man es von
  44. Heap bei Speichermangel kennt.
  45. * falls doch wird der Speicher wie gewohnt alloziert. Der Speicherbereich
  46. wird in der MemList des aufrufenden Tasks oder Prozesses registriert.
  47. Einwandfreie Funktion ist auch bei mehreren parallellaufenden Tasks, die
  48. auch unabhängig voneinander erzeugt und terminiert werden können,
  49. gewährleistet. Die Prozeduren sind reentrant.
  50.  
  51. Ein Deallozieren von Speicher, den man gar nicht alloziert hat führt nicht
  52. zum Guru, sondern wird abgefangen.
  53.  
  54. YesNoRequest
  55. ------------
  56. Dies ist eine Vereinfachung von AutoRequest(). Sie wird intern von
  57. Allocate, AllocMem (bei Speichermangel) und von RecoverableExit verwendet.
  58. Als "Zugabe" wurde die Prozedur auch im Definition-Module aufgeführt und
  59. somit für jedermann zugänglich gemacht. Die Parameter dürften
  60. selbsterklärend sein (siehe auch Intuition.AutoRequest).
  61.  
  62. RecoverableExit
  63. ---------------
  64. Dies ist gewissermaßen die Kombination aus Arts.BreakPoint und Arts.Error.
  65. Während BreakPoint nach beantworten des Requesters immer weitermacht, und
  66. Error immer abbricht, kann der Benutzer bei RecoverableExit selbst
  67. entscheiden.
  68. Die Prozedur verwndet die Variablen Window und ErrHeader (siehe dort).
  69.  
  70. ReqBody: Zeiger auf den String der "Requester-Überschrift"
  71. PosText: Zeiger auf den Text im linken Gadget (Programm fortsetzen)
  72. NegText: Zeiger auf den Text des rechten Gadget (abbrechen)
  73.  
  74. DeadEndExit
  75. -----------
  76. Entspricht Arts.Error, mit dem Unterschied, daß nicht die häßliche Meldung
  77. "Modula-2 Programmunterbruch" erscheint. Stattdessen wird ErrHeader (siehe
  78. unten) und darunter ReqBody angezeigt.
  79.  
  80. ExitQuiet
  81. ---------
  82. ermöglicht das korrekte beenden des Programms von jeder beliebigen Stelle
  83. aus (auch vom 671sten rekursiven Funktionsaufruf...). Ebenso wie auch bei
  84. DeadEndExit und RecoverableExit funktioniert hierbei der
  85. TermProcedure-Mechanismus ordnungsgemäß.
  86.  
  87. Window
  88. ------
  89. Diese Variable wird beim Aufruf von AutoRequest() durch MemSystem verwendet
  90. und sollte vor Verwendung von Prozeduren dieses Moduls initialisiert
  91. werden. Zwar funktioniert meines Wissens nach auch alles einwandfrei, wenn
  92. "Window" nicht initialisiert ist bzw. auf NIL steht, aber mit rücksicht auf
  93. die Aufwärtskompatiblität sollte man sich trotzdem an die Konventionen
  94. halten.
  95.  
  96. ErrHeader
  97. ---------
  98. Ist die Überschrift jedes Requesters, der von MemSystem erzeugt wird.
  99.  
  100. minMemory
  101. ---------
  102. gibt die größe des Speichers an, der minimal noch freibleiben muß, damit
  103. die korrekte Funktion des Systems gewährleistet ist. Default ist 20kB, was
  104. für einige Notfall-Requester oder Alerts ausreicht.
  105.  
  106. Hysteresis
  107. ----------
  108. Damit nach einem Speichermangel wieder Speicher alloziert werden kann, muß
  109. mindestens minMemory+Hysteresis Speicher frei sein. Die Hysterese wurde
  110. eingeführt, damit bei einem Arbeiten an der minMemory-Grenze nicht all paar
  111. Sekunden ein Requester erscheint, sondern der Speicher nach einem
  112. erfolgreichen "Retry" wieder für eine Weile reicht. Default ist 30kB.
  113.  
  114. Konstanten
  115. ----------
  116. Für die Prozeduren YesNoRequest und RecoverableExit werden einige
  117. vordefinierte Texte wie z.B. "Retry", "Cancel" usw. bereitgestellt, um den
  118. Aufwand des Arbeitens mit MemSystem möglichst gering zu halten.
  119.  
  120. Anmerkung zur neuen Version 1.1e
  121. --------------------------------
  122. Die alte Version arbeitete nicht einwandfrei, wenn das Programm vom CLI
  123. aus gestartet wurde. Der nicht zurückgegebene Speicher wurde erst bei
  124. EndCli freigegeben. Die neue Version gibt den mit MemSystem allozierten
  125. Speicher beim Programmende korrekt zurück.
  126.  
  127. Multitasking
  128. ------------
  129. Die Multitaskingfähigkeit von MemSystem hat natürlich nur einen Sinn, wenn
  130. auch in Modula Multitasking programmiert werden kann. Zur Zeit arbeite ich
  131. immer noch an einem Modul, das diese Fähigkeiten in Modula unterstützt.
  132. "TaskSupport" wird wahrscheinlich auf einer der nächsten Amok-Disketten
  133. erscheinen. Als Warnung sei gesagt, daß die Prozedur ExecSupport.CreateTask
  134. zumindest bis zur Compilerversion 3.11d nicht einwandfrei funktioniert
  135. (stürzt manchmal und nicht reproduzierbar ab). Falls jemand schon
  136. Erfahrungen mit Multitasking in Modula gemacht hat, würde es mich freuen,
  137. wenn er sich mit mir in Verbindung setzen würde.
  138.  
  139. ___________________________
  140.  
  141. Viel Spaß mit MemSystem!
  142.  
  143. Bene
  144.